Distributed database remote backup

ABSTRACT

Generating, by a first primary site that is included in a group of primary sites of a distributed database system, a commit action redo log message for a commit action performed by the first primary site for a first database transaction, the commit action redo log message including a transaction ID for the first database transaction and a transaction order indicator that represents an order of database transactions in a group of database transactions performed at one or more primary sites of the group of primary sites; and sending, by the first primary site, the commit action redo log message, for a corresponding first standby site that backs up the first primary site.

RELATED APPLICATIONS

This is a continuation application of U.S. patent application Ser. No.17/174,204, filed Feb. 11, 2021, the contents of which are incorporatedby reference.

TECHNICAL FIELD

The present application relates to data management, in particular tomethods and systems for synchronizing data in standby sites with primarysites in a distributed computer system.

BACKGROUND

In data management, a distributed database transaction can be a databasetransaction that is synchronized among (or is managed in concert with)multiple participating databases, which are distributed among differentphysical locations. The multiple participating databases of thedistributed system can include a plurality of primary databases, each ofwhich corresponds to a primary site, and a plurality of standby orbackup databases, each of which corresponds to a standby site. Eachstandby site corresponds to a primary site and synchronizes to thelatest changes that have been made in the primary site. The standby siteserves as a slightly stale mirror of the primary site data as thestandby site maintains a replicated database that is close to, but not areal-time copy of, the primary site database. Accordingly, recovery ofdata from the standby site, if and when required, is called asynchronousdata recovery.

In order to support data recovery in the event of a failure, eachprimary site records all changes in redo logs, and the primary site willsend redo log updates recording additional database changes to itscorresponding standby sites. Once the standby site receives the redo logupdates, the standby site applies the received redo log updates,resulting in synchronization with the primary site.

In the case where a primary site fails, the corresponding standby sitecan be used either to restore the primary site or be promoted to replacethe primary site, with minimum latency.

Accordingly, it is desirable to provide a method and system to enable astandby site to mirror changes made to its corresponding primary siteaccurately to fulfill atomicity and dependency requirements with minimaldivergence and maximal parallelism to support an asynchronous datarecovery scenario.

SUMMARY

According to a first example aspect is a method that includes:generating, by a first primary site that is included in a group ofprimary sites of a distributed database system, a commit action redo logmessage for a commit action performed by the first primary site for afirst database transaction, the commit action redo log message includinga transaction ID for the first database transaction and a transactionorder indicator that represents an order of database transactions in agroup of database transactions performed at one or more primary sites ofthe group of primary sites; and sending, by the first primary site, thecommit action redo log message, for a corresponding first standby sitethat backs up the first primary site.

In some examples of the first aspect, the transaction order indicatorincludes a vector that comprises a respective log sequence number foreach of the primary sites in the group of primary sites, the logsequence number for each of the primary sites corresponding to a commitaction performed by the respective primary site.

In examples of one or more of the preceding aspects, the method includesreceiving, at the first primary site, the log sequence numberscorresponding to the commit actions performed by other primary sites inthe group of primary sites, wherein the log sequence number included inthe transaction order indicator for each primary site corresponds to thelast commit action performed by the primary site as known to the firstprimary site.

In examples of one or more of the preceding aspects, the method includesreceiving, receiving, by the first primary site, notification of thetransaction ID for the first database transaction from a coordinatorthat assigns incremental transaction IDs to database transactions; andproviding, by the first primary site, notification for the coordinatorthat the first primary site is prepared to commit the first databasetransaction, wherein the log sequence numbers corresponding to thecommit actions performed by the other primary sites in the group ofprimary sites are received by the first primary site from thecoordinator.

In examples of one or more of the preceding aspects, the method includesreceiving, at the first standby site, the commit action redo log messageand determining based on the log sequence numbers included in thetransaction order indicator when to commit the first databasetransaction.

In some example of the first aspect, the transaction order indicatorincludes a commit sequence number assigned by a coordinator to the firstdatabase transaction that indicates when the first database transactionis committed at one or more of the primary sites relative to otherdatabase transactions included in the group of database transactions.

In examples of the preceding aspect, the method includes receiving,receiving, at the first standby site, the commit action redo log messageand determining, based on a comparison of the commit sequence numberassigned to the first database transaction with commit sequence numbersincluded in further commit action redo log messages received at otherstandby sites, when to commit the first database transaction.

In some examples, the comparison comprises comparing the commit sequencenumber assigned to the first database transaction to a consistent pointvalue, wherein the consistent point value is a minimum commit sequencenumber of a group that comprises a maximum commit sequence numberreceived at each of the standby sites that correspond to the group ofprimary sites.

In some examples of the first aspect: when the first databasetransaction falls below an importance criteria, the transaction orderindicator includes a commit sequence number assigned by a coordinator tothe first database transaction that indicates when the first databasetransaction is committed at one or more of the primary sites relative toother database transactions included in the group of databasetransactions; and when the first database transaction exceeds theimportance criteria, the transaction order indicator includes: (i) thecommit sequence number assigned by the coordinator to the first databasetransaction and (ii) a vector that comprises a respective log sequencenumber for each of the primary sites in the group of primary sites, thelog sequence number for each of the primary sites corresponding to acommit action performed by the respective primary site.

According to a second example aspect is a first primary site included ina group of primary sites that participate in database transactions. Thefirst primary site includes a processing system comprising one or moreprocessing units and one or more storage devices storing instructionsthat are operable, when executed by the one or more processing units, tocause the first primary site to perform operations comprising:generating a commit action redo log message for a commit actionperformed by the first primary site for a first database transaction,the commit action redo log message including a transaction ID for thefirst database transaction and a transaction order indicator thatrepresents an order of database transactions in a group of databasetransactions performed at one or more primary sites of the group ofprimary sites; and sending the commit action redo log message for acorresponding first standby site that backs up the first primary site.

According to a third example aspect is a method performed at a firststandby site that backs up a first primary site in distributed databasesystem that includes a group of primary sites each having respectivestandby sites, the method comprising: receiving a redo log message atthe first standby site in respect of a first transaction performed atthe first primary site, the redo log message including a transaction IDfor the first transaction and a first transaction order indicator thatindicates an order of the first transaction in a group of transactionscommitted at the group of primary sites; receiving information at thefirst standby site about transaction order indicators received at otherstandby sites; and determining, based on the redo log message and theinformation about transaction order indicators received at other standbysites, when to commit the first transaction at the secondary site.

In some examples of the third aspect, each transaction order indicatorincludes a vector that comprises a respective log sequence number foreach of the primary sites in the group of primary sites, the logsequence number for each of the primary sites corresponding to a commitaction performed by the respective primary site.

In some examples of the third aspect, the first transaction orderindicator includes a commit sequence number for the first transactionthat indicates when the first database transaction was committed at oneor more of the primary sites relative to other database transactionsincluded in the group of database transactions, and the transactionorder indicators received at the other standby sites each indicatecommit sequence numbers for transactions committed at the primary sitesthat correspond to the other standby sites.

In some examples of the third aspect, a consistent point value isdetermined, wherein the consistent point value is a minimum commitsequence number of a group that comprises a maximum commit sequencenumber received at each of the standby sites that correspond to thegroup of primary sites, wherein determining when to commit the firsttransaction at the secondary site is based on comparison of the commitsequence number for the first transaction with the consistent pointvalue.

According to a fourth example aspect is a first standby site included ina group of standby sites that back up a group of primary sites thatparticipate in database transactions. The first standby site includes aprocessing system comprising one or more processing units and one ormore storage devices storing instructions that are operable, whenexecuted by the one or more processing units, to cause the first standbysite to perform operations comprising: receiving a redo log message atthe first standby site in respect of a first transaction performed atthe first primary site, the redo log message including a transaction IDfor the first transaction and a first transaction order indicator thatindicates an order of the first transaction in a group of transactionscommitted at the group of primary sites; receiving information at thefirst standby site about transaction order indicators received at otherstandby sites; and determining, based on the redo log message and theinformation about transaction order indicators received at other standbysites, when to commit the first transaction at the secondary site.

According to a fifth example aspect is a computer readable medium thatstored instructions that when executed by a processing unit of adistributed database site can configure the site to perform one or moreof the above methods.

BRIEF DESCRIPTION OF THE DRAWINGS

Reference will now be made, by way of example, to the accompanyingfigures which show example embodiments of the present application, andin which:

FIG. 1 illustrates an example schematic diagram of a distributedcomputer system.

FIG. 2A shows an example of redo logs each including log sequencenumbers (LSNs) within a succession dependency vector (SDV) in a scenariowhere a single transaction is committed at a primary site, according toan example embodiment.

FIG. 2B shows an example of SDVs in a scenario where a plurality ofdependent transactions are committed at a plurality of primary sitesaccording to an example embodiment.

FIG. 3 illustrates an example of SDVs in a scenario where a transactionwith two-phase commit protocol (2PC) is committed on a plurality ofprimary sites according to an example embodiment.

FIG. 4A shows an example redo log including commit sequence numbers(CSNs) in a scenario where a single transaction is committed at aprimary site in accordance with one implementation of the presentdisclosure;

FIG. 4B is an example table and time diagram illustrating assignedrelationships between transaction identifier (ID) and commit sequencenumber (CSN) in accordance with one implementation of the presentdisclosure;

FIG. 4C illustrates an example of redo log updates received at aplurality of standby sites at different times in accordance with oneimplementation of the present disclosure;

FIG. 4D illustrates a further example of redo logs updates received at aplurality of standby sites at different times;

FIG. 4E illustrates a further example of redo logs updates received at aplurality of standby sites at different times;

FIG. 5 is a block diagram illustrating a processing system which may beused in one or more primary sites of FIGS. 1-4A, or one or more standbysites of FIGS. 1, 4C-4E, or one or more coordinators, according toexample embodiments.

Like reference numerals are used throughout the Figures to denotesimilar elements and features. While aspects of the invention will bedescribed in conjunction with the illustrated embodiments, it will beunderstood that it is not intended to limit the invention to suchembodiments.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS

The present disclosure teaches methods and systems for managingasynchronous data recovery in a distributed computer system, in order tomaintain database consistency and integrity between a primary site and acorresponding standby site. In this disclosure, a site can refer to adatabase instance, which is a set of software implemented memorystructures that are used to manipulate data in a database. A databasecan refer to a set of files that store data and metadata. In someexamples, database files may be written to a persistent read/writestorage such as a disc storage. A site (e.g., database instance) may beimplemented by a combination of a processing system and machine readableinstructions executable on the processing system. In some examples, eachsite may be hosted by a single processing system such as a computer. Insome examples, multiple sites may be hosted on a single processingsystem.

In this disclosure, a database transaction refers to a logical, atomicunit of work that is independently executed for data retrieval orupdates, and can include one or more actions (also known as operations)that implement one or more changes to a database. In this regard, adatabase transaction includes an indivisible and irreducible series ofactions that must all be completed. This means that in order forparticipating sites to complete and save a transaction (also referred toas “commit”) all of the actions in the transaction must be completed.Otherwise, the transaction must be aborted and all of the actions rolledback. Examples of actions that can be performed by a site includeactions that enable a site to store, modify, delete and retrieve data.

FIG. 1 presents an example of a distributed computer database system 100according to aspects of the present disclosure. Distributed computerdatabase system 100 includes a plurality of primary sites 102(1) to102(n) (generically referred to collectively as primary sites 102 orindividually as a primary site 102(i)) and a plurality of standby sites104(1) to 104(n) (generically referred to collectively as standby sites104 and individually as a primary site 104(i)). Each primary site 102(i)has a corresponding standby site 104(i). Each primary site 102(i)manages a database 105(i), and each corresponding standby site 104(i)manages a duplicate database 105′(i) that is a copy of its respectiveprimary site 102(i)'s database 105(i). In some examples, when a primarysite 102 grows too large it may be split into multiple primary shards. Aused in this disclosure, “when” can refer to a time when circumstancescause a thing to occur, which may not necessarily be a particular clocktime or a particular chronological point or interval. Each primary shardwill have its respective standby shard. For the present disclosure, a“shard” can also be considered to be a “site”. Primary sites 102 andstandby sites 104 may be connected to a communication network system 150that may include one or more networks including, for example, theIntranet, one or more intranets, wired networks, wireless networks,virtual private networks, and combinations thereof.

In example embodiments, transactions performed by primary sites 102 aremanaged by a transaction coordinator 122. A transaction coordinator 122can be a module that is implemented by a combination of machine-readableinstructions executable on a processing system. In some examples,different coordinators 122 may be used to manage different transactionsor groups of transactions. In some examples, a coordinator 122 may beco-hosted on a processing system with a primary site 102.

Each primary site maintains a respective redo log file 110 in a definedformat which logs a history of all changes made to the primary site102(i)'s database 105(i). A primary site 102(i) is configured togenerate (produce, in any fashion) a new redo log 106(i) for each actionthat the site 102(i) performs that changes its database 105(i). Everytime the primary site 102(i) generates a new redo log 106(i), it adds acopy of the redo log 106(i) to its redo log file 110 and also provides aredo log message 112(i) that includes a copy of the redo log 106(i) forits corresponding standby site 104(i). Standby site 104(i) performs theaction included in the redo log 106(i) to manage duplicate database105′(i). An illustrative example of a redo log file 110, correspondingto primary site 102(1), is shown in FIG. 1 . The redo log file 110includes a plurality of successively generated redo logs. Eachtransaction ends with a redo log that is recorded for a “Commit” action,with an illustrative commit action redo log 106C(1) being surrounded bya dashed block in FIG. 1 . As shown, each redo log 106(1) identifies arespective action (a “commit” action in the case of commit action redolog 106C(1)) FIG. 1 ), a transaction ID (e.g. Trx_1) that identifies thetransaction that the action is performed by primary site 102(1) inrespect of, and a log sequence number LSN (e.g., LSN=4). In exampleembodiments, transaction ID's are incrementally assigned by acoordinator 122 each time a new transaction is received. An LSN isincrementally assigned by the primary site 102(i) to each redo log106(i) that it generates. Accordingly, the LSN values for each primarysite 102(i) are locally generated values, with a new LSN value beinggenerated for each redo log 106(i) (including commit action redo log(106C(i)) generated at the site.

In examples, each primary site 102(i) maintains a local transactionorder indicator, for example, a site dependency vector (SDV) 108(i),that it stores in conjunction with redo log file 110. A transactionorder indicator represents (colloquially, stands for or corresponds to),an order (sequence) of database transactions in a group of databasetransactions. A vector is an ordered set or array of numbers, typicallywith significance attached to the order in which the numerical valuesappear in the vector, as well as the numerical values themselves. TheSDV 108(i) is used to track the current (e.g., maximum) LSV values forcommit actions performed at the primary site 102(i) and other primarysites 102, thereby providing a indication of the position of eachprimary site 102 within the transaction log stream. SDV 108(1) includesa slot or element (S1, S2, . . . , Sn) for each of the primary sites102(1) to 102(n) that participate in at least some transactions includedin a global transaction log stream in a distributed computer databasesystem 100. The values that are included in the respective elements (S1,S2, . . . , Sn) of SDV 108(1) identify, based on the current informationavailable to the primary site 102(1), the LSN values of the last commitaction redo log 106C(1) to 106C(n) recorded by all primary sites 102(1)to 102(n) in the transaction log stream. For example, vector element S1can indicate the LSN for the commit action redo log 106C(1) of the lasttransaction committed by primary site 102(1), vector element S2 canindicate the LSN for the commit action redo log 106C(2) of the lasttransaction committed by primary site 102(2) (as known to primary site102(1)), and vector element Sn can indicate the LSN for the commitaction redo log 106C(n) of last transaction (as known to primary site102(1)) committed by primary site 102(n). In an example embodiment, thevalues of vector elements (S1, S2, . . . , Sn) are each set to the logsequence number (LSN:Trx) of the Commit action of the last knowntransaction as indicated by the primary site that performed the Commitaction. As will be explained in greater detail below, the SDVs 108(1) to108(n) are used to provide a vector of Lamport-style clocks that sitescan use to determine location in the transaction log stream. In exampleembodiments, the other primary sites 102 that are represented as commitaction LSN slots in the SDV of a particular primary site 102(i) may beless than n if the value of n exceeds a threshold. In such cases, therepresented primary sites 102 may the sites that are most likely to beinvolved in a dependent transaction with the primary site 102(i). Insome examples, the slot assignments in the SDV for a particular primarysite may be predetermined by a system administrator.

In example embodiments, when a primary site 102(i) performs an action inrespect of a transaction, the action is recorded in a respective redolog 106(i) at the primary site's redo log file 110 and a redo log 106(i)is sent, as part of a redo log message 112(i), to its correspondingstandby site 104(i). In example embodiments, the primary site's SDV108(i) is updated whenever the primary site 102(i) becomes aware that anew commit action has been performed by itself or another primary site.In example embodiments, primary site 102(i) includes its current SDV102(i) as part of the redo log message 112(i) every time the primarysite 102(i) reports a new commit action redo log 106C(i). A redo logmessage 112(i) that reports a new commit action redo log can be referredto as a “commit action redo log message”. In some alternative examples,the current SDV 108(i) may be included with every redo log message112(i) sent to standby site 104(i).

Once a standby site 104(i) receives a redo log 106(i) from itsrespective primary site 102(i), the standby site 104(i) can perform theaction specified in the redo log 106(i) to update duplicate database105′(i), and to update its own copy of a redo log file, to keepsynchronization with the primary site 102(i).

At some point, standby sites 104 that participate in a transaction mustmake a decision to commit the transaction or rollback the transaction.In this regard, a plurality of criteria are required in order for eachof the participating standby sites 104 to determine whether to rollbackor commit, including an atomicity requirement and a dependencyrequirement. The atomicity requirement means that all of the actions ina transaction must be performed for a standby site 104 to commit thetransaction, or else the actions of the transaction must all be rolledback. The dependency requirement means that a second transaction thatdepends on a first transaction will not be committed at the standby site104(i) unless the standby site 104(i) can confirm that the firsttransaction has been committed.

The present disclosure describes systems and methods for trackingtransaction dependency relationships among standby sites 104. Insituations where a standby site 104(i) does not know progress of actionsperformed by other standby sites 104 with respect to dependenttransactions, uncertainties can arise that make it challenging for astandby sites 104(i) to determine when and whether to committransactions described in the redo log messages 112(i) the standby sitehas received. The uncertainties can lead to a large recovery pointobjective (RPO) and a long recover time objective (RTO) for the standbysites 104 in order to keep data in the standby sites 104 consistent withchanges that occur in the corresponding primary sites 106. A large RPOmay lead to substantial divergences between a primary site and thecorresponding standby site, and a long RTO may cause backup with lessparallelism at standby sites. Furthermore, the long RPO and RTO may inturn cause inaccuracies and introduce errors for recovering data in adistributed computer database system when primary sites go down orotherwise fail. Accordingly, in at least some examples the methods andsystems disclosed herein may be used to improve efficiency and accuracyof distributed database systems.

According to example embodiments, in order to mitigate againstuncertainties that can arise as a result of unknown inter-transactiondependencies, the above mentioned the site dependency vector SDV 108(i)is used as a mechanism for tracking transaction dependencies amongbackup sites 104.

FIG. 2A illustrates a simplified example of the updating of a sitedependency vector (SDV) 108(1) of a primary site 102(1) in respect of asingle-site transaction Trx_1 that consists of a one or more databasechange actions that are all performed at the primary site 102(1). Thedashed block T0 illustrates the SDV 108(1) stored as part of log updatefile 110 at time T0 before primary site 108(1) commits transactionTrx_1. As noted above, SDV 108(1) will include n elements (S1:*, S2:*, .. . , Sn:*), with elements S1 to Sn representing, from the perspectiveof the primary site 102(1), the last known transaction committed byitself and the other primary sites 102(2) to 102(n), respectively. Thevalue included in each of elements S1 to Sn, respectively, is theprimary site 102(1)'s knowledge of the local LSN of last transaction forwhich a commit action was performed at each of the primary sites 102(i)to 102(n), respectively. Thus, the element values in SDV 108(1) canprovide information about committed transaction offsets in an overalllog stream for distributed computer database system 100 from theperspective of primary site 102(1). In the present example, “*” maydenote a null value, indicating that no prior transactions are known attime T0.

The dashed block T1 illustrates the SDV 108(1) at time T1 after theprimary site 102(1) has performed all database change actions that arepart of transaction Trx_1 and commits transaction Trx_1. In particular,the SDV element S1 that corresponds to the primary site 102(i) has beenset to S1:LSN_j, where “LSN_j” is a log sequence value (LSV)corresponding to the commit action for transaction Trx_1. By way ofexample, if SDV 108(1) vector element value S1=“0” at the start oftransaction Trx_1, and Trx_1 included 2 database change actions atprimary site 102(1) followed by a Commit action at primary site 102(1),then the LSN value would be incremented by 3 integer units such thatS1:LSN_j=S1:3 (assuming no intervening actions in respect of othertransactions). In the example of FIG. 2A, primary site 102(1) is notaware of any other transactions committed by other primary sites, and soall of the other SDV element values S2 to Sn retain their previousvalues (e.g., “*” or “null” in the illustrated example).

In an example real-time-update embodiment, when performing therespective actions that are included in transaction Trx_1, the primarysite 102(1) will prepare and send a respective redo log 106(1) to itsstandby site 104(1) on an action-by-action basis. When the primary site102(1) performs a commit action (i.e., when it writes the transactionTrx_1 to a non-transitory database storage such as a disc), itimmediately provides a commit action redo log 106C(1) of the commitaction for standby site 104(1). In example embodiments, the currentupdated SDV 108(1) will be included with the redo log message 112(1)that includes the commit action redo log 106C(1).

In some examples, primary site 102(1) may send redo log message 112(1)(including commit action redo log 106C(1) and SDV 108(1)) in a networkcommunication that is addressed to corresponding standby site 104(1). Insome examples, primary site 102(1) may send redo log message 112(1) toan intermediate central storage site for retrieval by standby site104(1). At the corresponding standby site 104(1), once the redo logmessage 112(1) (including commit action redo log 106C(1) and updated SDV108(1) (e.g., (S1:LSN_i, S2:*, Sn:*)) has been received, thecorresponding standby site 104(1) will determine whether the transactionTrx_1 can be committed at the standby site 104(1) based on the contentof SDV 108(1) (e.g., (S1:LNS_i, S2:*, . . . , Sn:*)) in the received SDV108(1).

In this regard, the standby site 104(1) analyzes all the components(e.g., “S1:LSN_i”, “S2:*”) included in the received SDV 108(1) and findsout that a value (e.g., S1:LSN_i) corresponding to the primary site S1is greater than 0, and the values (e.g., *) corresponding to the otherprimary sites 102(2) to 102(n) are null (“*”). Standby site 104(1) willhold off committing transaction TRX_1 until it receives informationindicating that the LSN values for other sites are at least equal toLSN_i. The LSN information can come from one of two sources: either inthe SDV 108(1) received from the primary site 102(1), or by directpolling of the other standby site 104(2) by the standby site 104(1).When standby site 104(1) polls other sites standby sites 104(2), it willupdate each of the values in the respective SDV 108(1) slots to thehighest known LSN for each of the respective sites.

In this regard, as respective commit action redo logs 106(i) including arespective SDV 108(i) are provided by each of the primary sites 102(i)for their respective standby sites 104(i), each standby site 104(i) candetermine when and if transactions should be committed based on valuesof LSNs included in the received SDVs, in order to support a possiblefuture asynchronous data recovery. Such a method may help to improveaccuracy of performing asynchronous data recovery at standby sites byusing the vector as a Lamport clock in the received redo log, which mayin turn lead to reduced RPO.

An example will now be described in the context of a multi-sitetransaction, for the case where the number n of primary sites n=2. Inthis regard, FIG. 2B illustrates an example of using SDV vectors 108(1),108(2) as Lamport clocks with respect to a first transaction Trx1 and asecond Transaction Trx2. FIG. 2B shows the SDV vectors 108(1) and 180(2)for two primary sites 102(1), and 102(2), respectively, at differentsuccessive time periods, namely time T1, . . . ,T3, which T1 refers to aduration of time that proceeds time T2, etc. At time T0, both theprimary sites 102(1) and 102(2) are initialized, and their respectiveinitialized SDV 108(1), 108(2) are populated with null values, denotedas (S1:*, S2:*).

Instructions for a first transaction arrive at coordinator 122, whichassigns an incremental transaction ID, “Trx_1” to the first transaction.First transaction Trx_1 is a single site transaction that includesactions performed at primary site 102(2) (e.g., add 10 books to site 2inventory) and no actions at primary site 102(1). By time T1, alldatabase change actions of first transaction Trx_1 are completed, andrespective redo logs have been sent to its standby site 104(2). Primarysite 102(2) performs a commit action for first transaction Trx_1, andupdates its SDV 108(2) to include the local LSN (denoted as LSN_Trx1)generated by primary site 102(2) for the commit action log 106C(2) forfirst transaction Trx1. Thus, at time T1, SDV 108(2) can be denoted as:(Si:*, S2:LSN_Trx1). The component “S2:LSN_Trx1” of the vector (Si:*,S2:Trx1) identifies the LSN number of the last commit action performedby primary site 102(2). Primary site 102(2) sends a redo log message112(2) including commit action redo log 106C(2) and the current SDV108(2) (Si:*, S2:Trx_1), to its respective standby site 104(2).

Coordinator 122 receives instructions for a second transaction andassigns an incremental transaction ID, “Trx_2” to the secondtransaction. In the illustrated example, the second transaction Trx_2includes a database change action (e.g., add 5 books to site 1inventory) that requires a change to the database of primary site106(1), as well as a retrieve action (e.g., does site 2 already have atleast 5 books?) that requires a retrieval of information from thedatabase of primary site 106(2). In this regard, second transactionTrx_2 includes a condition that the change action will only be performedat primary site 102(1) if the retrieve action response from primary site102(2) meets a defined criteria (e.g., only add 5 books to site 1inventory if site 2 already has at least 5 books).

Prior to time T2, coordinator 122 notifies primary site 102(1) of theincremental transaction ID for second transaction (i.e., Trx_2). Duringtime T2, primary site 102(1) provides a request for information fromprimary site 102(2) and receives a response from primary site 102(2). Inat least some example's, the request and response is facilitated bycoordinator 122. Furthermore, as part of the response, the primary site102(1) also receives a current copy of the SDV 108(2) for the primarysite 102(2). The primary site 102(1) updates its own SDV 108(1) based oninformation included in the SDV 108(2) received from primary site 102(2)by doing an element by element comparison and updating each element tothe largest LSN value. In the illustrated example, the entry“S2:LSN_Trx1” in SDV 108(2) will have a larger offset value in thetransaction log stream value than the “null” value “S2:*” currentlystored in the element location of SDV 108(1) that corresponds to primarysite 102(2). Accordingly, primary site 102(1) will update its own SDV108(1) to (S1:*, S2:LSN_Trx1).

At time T3, all retrieval and change actions of second transaction Trx_2are completed, respective redo log messages have been sent to secondarysite 102(1), and primary site 102(1) performs a commit action for secondtransaction Trx2, and updates its SDV 108(1) to include the LSN for thecommit action it has performed in respect of second Transaction Trx_2.Thus, at time T3, SDV 108(1) can be denoted as: (S1:LSN_Trx2,S2:LSN_Trx1). The component “S1:LSN_Trx2” of the vector (S1:LSN_Trx2,S2:LSN_Trx1) identifies the local LSN of the last commit action byprimary site 102(1). Primary site 102(1) also provides, for itsrespective standby site 104(1), a redo log message 112(1) that includescommit action redo log 106C(1) for transaction Trx_2, along with the SDV108(1) (S1:LSN_Trx2, S2:LSN_Trx1).

As the second primary site 102(2) does not perform any actions thatrequire a change to its database or redo log from time T1 to time T3,the SDV 108(2) of second primary site 102(2) remains the same in theexample of FIG. 2B after time T1 (i.e., at times T1, T2 and T3, SDV108(2)=(S1:*, S2:LSN_Trx1)

With respect to first and second corresponding standby sites 104(1) and104(2), the standby sites 104(1) 104(2) respectively receive the updatedSDVs 108(1) and 108(2) provided at times T3 and T1 respectively.

Upon receiving the commit action redo log 106C(2) that is provided byits corresponding primary site 102(2) at time T1, the standby site104(2) can compare the newly received SDV 108(2) (e.g., (S1:*,S2:LSN_Trx1)) with its existing SDV (e.g., (S1:*, S2:*)) and determinethat the corresponding LSN value for its primary site 102(2) has changedfrom “*” to “LSN_Trx1”, and that no other values in the SDV havechanged. After time T3, if standby site 102(2) polls standby site 104(1)it will determine that the current SDV vector 108(1) is (S1:LSN_Trx2,S2:LSN_Trx1), and update its own SDV vector accordingly. Assuming thatthe value of LSN_Trx1 is less than or equal to LSN_Trx2, then standbysite 102(2) will determine that it can commit transaction Trx1.

Accordingly, the respective SDVs act as a form of vector clocks thatenable standby sites 102 to determine if the transactions that they areto backup are dependent on other transactions, and if those othertransactions have been successfully committed. This can support datarecovery by keeping the backup sites 104 in close alignment with theircorresponding primary sites. The SDVs 108 use relatively small amountsof memory and transmission resources (particularly if sent only withcommit action redo logs) to track transaction dependencies acrossmultiple sites, and thus have low storage space requirements. In atleast some applications, the use of SDVs enables the computer resourcesused in system 100 to ensure accurate recovery at the standby sites tobe optimized.

Reference is now made with respect to FIG. 3 , which shows an example ofa transaction Trx2 that requires change actions on a plurality ofprimary sites 102(1), 102(2), in accordance with example embodiments.

A transaction that commits on a plurality of primary sites (e.g., across-store transaction) typically relies on a two-phase commit protocol(2PC), which requires computer implemented coordinator 122 to coordinatethe actions of the sites that participate in the transaction. A 2PCtransaction includes a Prepare phase and a Commit phase. In the Preparephase, participants (e.g., the plurality of primary sites) perform theirrespective actions without writing the results to the persistentdatabase storage (e.g., a disc), including all necessary steps toprepare resources for committing the transaction, and then notifycoordinator 122. In the Commit phase, based on received preparenotifications (e.g., voting) from the participants, the coordinatordecides whether to commit (if all participating sites have voted “yes”)or abort the transaction, and notifies the decision to all theparticipants. The participants then implement the decision (e.g., commitor abort the transaction) with the prepared resources. In some examples,in distributed computer database system 100, a network node isdesignated as the coordinator 122 (which may also be a primary site, ora different site) and the plurality of primary sites associated with thetransaction are designated as participants.

An illustrative 2PC transaction Trx2 involving two primary sites 102(1)and 102(2) and a coordinator 122 is presented in FIG. 3A. Prior to timeT0, both primary sites have respectively committed a prior transactionTrx1, but are unaware that the other has committed transaction Trx1.Accordingly, the SDV 108(1) for primary site 102(1) is (S1:LSN_Trx1,S2:*), and the SDV 108(2) for primary site 102(2) is (S1:*,S2:LSN_Trx2). These SDV's 108(1) and 108(2) have previously beenprovided to the first and second standby sites 104(1), 104(2),respectively, when the transaction Trx1 was committed by first andsecond primary sites 102(1) and 102(2). At time T0, first primary site102(1) has prepared the resources that it will need to executetransaction Trx2 and has performed, in a buffer, all actions included inthe transaction Trx2 with the exception of the commit action. Redo logs106(1) have been sent to first standby site 104(1) in respect of each ofthe pre-commit actions. The first primary site 102(1) also providesnotification to coordinator 122 that it has prepared transaction Trx2,and also provides its current SDV vector 108(1) (S1:LSV_Trx1, S2:*) tocoordinator 122.

Similarly, second primary site 102(2): prepares transaction Trx2 andprovides coordinator 122 with notification that it has preparedtransaction Trx2 and provide coordinator 122 with a copy of SDV vector108(2) (S1:*, S2:LSV_Trx1).

Once the coordinator 122 receives notifications for all the primarysites 102(1), 102(2) that are participating in transaction Trx2, thecoordinator 122 decides whether the primary sites have collectivelyvoted to commit the transaction Trx2 or abort the transaction 2. Ifcoordinator 122 determines that transaction Trx2 is to be committed, thecoordinator 122 extracts a respective maximum commit action SLN valuefor each primary site from its respective slot location in each SDV108(1), 108(2) and merges all the extracted maximum commit action LSNvalues into a merged SDV 124, represented as (S1:LSN_Trx1, S2:LSN_Trx1)in FIG. 3 . It will be noted that S1:LSN_Trx1 will be the local LSNgenerated by primary site 102(1) for the commit action corresponding totransaction Trx1 and S2:LSN_Trx1 will be the local LSN generated byprimary site 102(2) for the commit action corresponding to transactionTrx1, and accordingly these two LSN values may not be equal, but will berepresentative of where each of the respective primary sites 102(1) and102(2) are in terms of committing transactions included within a groupof successive transactions (e.g. a transaction stream). The coordinator122 provides a message for the first and second primary sites 102(1),102(2) that: (i) informs the sites to respectively proceed withcommitting transaction Trx2, and (ii) includes a copy of the merged SDV124. After receiving the message (for example, at time T2), each primarysite 102(1) and 108(2) updates its respective SDV 108(1) and 108(2)based on the merged SDV 124. For example, after the update, both thevectors 108(1), 108(2) are updated to be consistent with the merged SDV124, (S1:LSN_Trx1, S2:LSN_Trx1).

Each primary site 102(1), 102(2) then enters the Commit phase andcommits transaction Trx2 (e.g., writes the transaction to disc). Uponcompletion of the Commit phase (for example, at time T3), each primarysite 102(1), 102(2) respectively: (i) generates a respective commitaction redo log 106C(1), 106C(2) for the Commit action for transactionTrx2; (ii) updates its respective SDV 108(1), 108(2) to include the LSNfrom the Commit update log for transaction Trx2; and (iii) provides arespective redo log message 110(1), 110(2) (including, respectively,commit action redo logs 106C(1), 106C(2) and the updated SDVs 108(1),108(2)) for its respective standby site 104(1), 104(2). In the case ofthe primary site 102(1), at time T3 the updated SDV 108(1) will be:(S1:LSN_Trx2, S2:LSN_Trx1), indicating primary site 102(1)'s currentknowledge that transaction Trx2 has been committed at primary site102(1). In the case of the primary site 102(2), at time T3 the updatedSDV 108(2) will be: (S1:LSN_Trx1, S2:LSN_Trx2), indicating primary site102(2)'s current knowledge that transaction Trx2 has been committed atprimary site 102(2).

In the absence of any failures, standby site 104(1) will receive SDV108(1) (S1:LSN_Trx2, S2:LSN_Trx1); standby site 104(2) will receive SDV108(2) (S1:LSN_Trx1, S2:LSN_Trx2). If the redo logs and SDV's arereceived as expected, the transaction Trx2 will be carried out at thestandby sites 104(1), 104(2), keeping the standby sites and databasesclosely aligned with the primary sites and databases. If, however, theSDV's are not received or include LSV values that are lower thanexpected, either standby site 104(1), 104(2) can notify a coordinatorsite that will then make a determination whether to abort, or take someother action (e.g., wait) with respect to the transaction Trx2.

In the above embodiments, each of group of primary sites 102 employs arespective SDV 108(i) as a transaction order indicator to track therespective positions or offsets of the commit actions of a group ofinteracting primary sites 102 in a transaction stream. As noted above,each site's SDV 108(i) includes a respective value element for eachprimary site 102(i) in the group of interacting primary sites 102. Eachprimary site 102(i) tracks its own position in the transaction stream bysetting its own corresponding commit action LSN in its SDV 108(i) to theLSV to the last commit action recorded in the commit action redo log106C(i) of the primary site 102(i). Each primary site 102(i) tracks theown position in the transaction stream of the other primary sites 102 bysetting the value elements in its SDV 108(i) for the other primary sites102 based on the most recent site transaction stream positioninformation received in respect of the other primary sites 102. Thistransaction stream position information may be acquired indirectly fromthe other primary sites 102 through a coordinator 122 (for example, inthe case of 2PC transaction of FIG. 3A) or, in some examples, directlyfrom other primary sites 102 (for example, in the case ofcoordinator-free transaction of FIG. 2B). In examples, whenever aprimary site 102(i) sends a redo log 106(i) in respect of a commitaction to its backup site 104(i), it includes the latest version of itsSDV 108(i).

At the corresponding standby sites 104, the received SDVs can be used toverify that site backup among the multiple sites is occurring in such away as to meet transaction dependency requirements with minimaldivergence between the primary sites and the standby sites. In at leastsome examples, use of such a Lamport clock-style synchronization ofdependencies of the primary sites 102 can eliminate the need forrecovery point checks between standby sites. The above described Lamportclock-style synchronization method and system has some overhead as itrequires the storage and updating of a SDV at each site. However, in atleast some examples, the above described methods and systems enable REDOlogs to be applied on standby sites with minimal latency (i.e., smallRPO) and minimal RTO, while satisfying atomicity dependencyrequirements.

Further examples will now be described that use a commit sequence number(CSN) rather than an SDV of LSNs as a transaction order indicator fortracking transaction stream positions. In the example of FIG. 4A,primary sites 102 co-operate with coordinator 122 to obtain transactionsIDs and CSNs for transactions that are committed on primary sites 102.As shown in FIG. 4A, at time T0, coordinator 122 receives instructionsregarding a multi-site transaction that involves primary sites 102(i)and 102(i+1). Coordinator 122 assigns an incremental transaction ID(e.g., Trx_j) to the transaction, and notifies provides primary sites102(i) and 102(i+1) of the assigned transaction ID. The primary sites102(i) and 102(i+1) respectively perform the prepare phase fortransaction Trx_j, and then send respective prepare messages tocoordinator 122 (e.g., at times T2 and T2′, respectively) indicatingthat the primary sites 102(i) and 102(i+1) are each prepared to committransaction Trx_j. Upon receiving notification from all participatingprimary sites 102 that they are prepared to commit transaction Trx_j,the coordinator 122 increments a global transaction commit sequencenumber (CSN) to assign a CSN number to the commit transaction Trx_j(e.g. CSN for transaction Trx_j=CSNk).

The coordinator 122 then notifies each primary site 102(i), 102(i+1)that all sites are prepared to commit transaction Trx_j and of the CSN(e.g., CSNk) assigned to the transaction. Upon receiving the commitnotification and the CSN for transaction commit transaction Trx_j fromthe coordinator 122, each participating primary site 102(i), 102(i+1):(i) proceeds with committing transaction Trx_j; (ii) generatesrespective commit action redo logs 106C(i), 106C(i+1) that is added toits local redo log file 110; and (iii) sends a respective redo logmessage 112(i), 112(i+1) (each including a respective commit action logrecord 106(i), 106(i+1) and the CSN value assigned to transactionTrx_j), to its corresponding standby site 104(i), 104(i+1).

As will be explained in greater detail below, the redo log message110(i) that includes commit action redo log 106C(i) received at standbysite 104(i), includes a transaction ID and the CSN for the committedtransaction (e.g., Trx_j, CSNk). The standby site 104(i) can compare theCSN information included in commit action redo logs 106C(i) fortransactions with CSN information that the standby site 104(i) receivesfrom other standby sites 104 to determine if and when transactionsshould be committed at the standby site 104(i). Including a CSN andtransaction ID pair into redo log messages 110(i) for committedtransactions may enable atomicity and dependency requirements to besatisfied accurately. Furthermore, as the coordinator is responsible forcoordinating the actions of participating sites, RTO performance may beimproved.

FIG. 4B is an illustrative example of a table 401 and timing diagram 402showing different assigned transaction ID/CSN pairs. Every transactionis assigned a unique transaction ID and a unique CSN, with a subsequentcommitted transaction in a transaction stream having a higher value CSNthan an earlier committed transaction. Taking transactions 4 and 5(transaction IDs Trx4 and Trx5) as an example, a value of 6 is used as aCSN for the transaction 4, and a value of 5 is assigned for thetransaction 5. Therefore, if a standby site receives one redo log updatethat includes a relationship identifying transaction ID Trx4 correspondsto CSN value 6 and the other a redo log update that includes a TrxID/CNS pair:Trx5:CSN 5, the standby sites can tell that transaction 5 iscommitted prior to the transaction 4 by comparing values of CSNs (e.g.,CSN 6>CSN 5) from the received redo log updates.

In respect of two transactions having dependent relationship (e.g., asecond transaction depends on a first transaction), the CSN value of thesecond transaction will be greater than the CSN value of the firsttransaction. For example, where a standby site receives a redo log wheretransaction Trx2 is assigned a CSN with a value of 3, the standby sitecan assume that the transaction Trx2 will not depend on any othertransaction that has a CSN that is larger than 3.

A theorem of atomicity and dependency correctness for a CSN basedtransaction log stream tracking method can be stated as follows: For atransaction TrxA with a CSN value of X, if every standby site in a groupof standby sites has seen a maximum CSN at least as large as X, then thetransaction TrxA can be committed and both atomicity and dependencyrequirements will be met.

Examples of standby site processing using CSN values in the context of a2PC transaction will now be described with respect to FIGS. 4C and 4D,in which distributed database system 100 includes first, second, andthird standby sites 104(1), 104(2) and 104(3).

In FIG. 4C, at time T0, first and second standby sites 104(1), 104(2)have respectively received redo logs from first and second primary sites102(1), 102(2) (not shown in FIG. 4C) indicating actions that are partof the “Prepare” stage for transaction Trx2. Third standby site 104(3)receives a commit action redo log 106C(3) from third primary site 102(3)that includes Trx1 has been committed and assigned CSN value of CNSN1(e.g., indicating that a first transaction Trx1, assigned CSN1, has beencommitted at third primary site 102(3)). The first, second, and thirdstandby sites 104(1), 104(2) and 104(3) all keep track of thetransaction IDs for which they have respectively received commit actionredo logs and the CSN values assigned to those transactions.Furthermore, the each of the first, second, and third standby sites104(1), 104(2) and 104(3) can learn from the other standby sites 104(1),104(2) and 104(3) what the maximum CSN value is that each of the otherstandby sites has been made aware of. In different examples,communication of this CSN information between standby sites 104(1),104(2) and 104(3) can occur through one or more of: (i) as part ofstandby site-to-standby site communications that occurs as part of atransaction; (2) a polling or reporting mechanism where standby-sitespoll each other or report to each other to determine the maximum CSNvalues that each has seen; and/or (3) through a standby coordinator 422that may be present in some examples for collecting and disseminatinginformation among the standby sites.

In example embodiments, based on its own maximum CSN value, and themaximum CSN value information that it receives it respect of the otherstandby sites, each standby site 104(i) can determine the minimum of themaximum CSN values that all of the standby sites 104(1) to 104(3) haveeach been notified of by the respective primary sites 102(1) to 102(3)up to that time. The minimum of the maximum CSN values is referred to asa “Consistent Point” (“CP”) value. Thus, at time TO, the most highestvalue CSN known to standby sites 104(1) and 104(2) is null value “*”.Based on the commit action redo log 106C(3) received from primary site102(3) for transaction Trx1, standby site 104(3) is aware of a maximumCSN value of CSN1. Accordingly, in the example of FIG. 4C, at time T0,the CP value (i.e., minimum of all the maximum CSN values observed inreceived commit action redo logs by each of the standby sites 104(1),104(2) and 104(3) up to that time) is the null value “*”, as neither ofthe primary sites 104(1) or 104(2) have received a CSN value. Each ofthe respective standby sites 104(1) to 104(3) can determine if that sitecan commit any of the transactions that is has received a CSN number inrespect of by comparing those received CSN numbers to the CP value. Inthe illustrated example of FIG. 4C, at time T0, standby sites 104(1) and104(2) have no pending transactions with CSN numbers. Standby site104(3) has received notification of CSN1, however CSN1 is greater thanthe CP value=“*” for the group of standby sites 104(1) to 104(3), sostandby site 104(3) elects to not commit Trx1 at time T0. In examplewhere a standby coordinator 422 is present, the standby coordinator cancollect the information required to determine the CP value and thendisseminate that information to the respective standby sites 104(11) to104(3). In examples where there is no standby coordinator, the standbysites 104(1) to 104(3) can collect the information required to determinethe CP value directly or indirectly from each other.

In FIG. 4C, at time T1, each of the first and second standby sites104(1), 104(2) receive respective redo log messages that respectivelyinclude commit action redo logs 106C(1) and 106C(3) from first andsecond primary sites 102(1), 102(2), for transaction Trx2, along withCSN value CSN3. This indicates that first and second primary sites102(1), 102(2) have each committed transaction Trx2 and that transactionTrx2 has been assigned a CSN=3 by the primary site coordinator 122. Themaximum CSN value observed at the standby sites 104(1) to 104(3) isCSN3, CSN3 and CSN1, respectively,

Thus, at time T1, the minimum maximum CSN is CSN=1, and thus the CPvalue is CP=1. Each of standby sites 104(1) and 104(2) will determinethat the CSN values of their respective transactions are greater thanthe current CP=1 value, and will elect to not commit any transactions.However, standby site 104(3) will determine that the transactionTrx1:CSN1 that it has not yet committed locally has a CSN value that isless than or equal to the current CP=1 value, and thus standby site102(3) will elect to commit transaction Trx1.

In FIG. 4C, at time T2, third standby site 104(3) receives a furtherredo log message 112(3) that includes commit action redo log 106C(3)from third primary site 102(3), indicating that transaction Trx4 canbeen committed at third primary site 102(3) and assigned a CSN value ofCSN6. Thus, at time T2, the minimum of the maximum CSNs that the standbysites 104(1) to 104(3) have each received with commit action redo logsis CSN=3, so the CP value at time T2 is CP=3. Standby sites 104(1) and104(2) can decide to commit transaction Trx2:CSN3 as CSN=3 is equal toor less than CP=3. Standby site 104(3) will hold off committingTrx4:CSN6 as CSN=6 is greater than CP=3.

FIG. 4D illustrates an example where redo log messages identifyingcommitted transactions and their assigned CSNs are received at standbysites 104 in an order different than an order that correspondingtransactions are committed at primary sites 102. FIG. 4D is similar toFIG. 4C except that at time T1, instead of receiving a message forcommit action redo log 106C(2) at standby site 104(2) identifyingTrx2:CSN3, standby site 104(2) receives a commit action redo log 106C(2)for a transaction Trx5 that has been assigned a CSN value of CSN5. Inthis case, although a transaction Trx2 with CSN3 is committed before atransaction Trx5 with CSN 5 at the primary site 102(2), the commitaction redo log corresponding to Trx5:CSN5 is received at the secondstandby site 104(2) prior the commit action redo log corresponding toTrx2:CSN3. Thus, at time T2, the CP value will be CP=3. Standby site104(1) can commit transaction Trx2:CSN3 as CSN=3 is equal to or lessthan CP=3. Standby site 104(3) will hold off committing Trx4:CSN6 asCSN=6 is greater than CP=3. Standby site 104(2) will hold off committingTrx5:CSN5 as CSN=5 is greater than CP=3.

The treatment of transaction Trx2 by standby site 104(2) will now bedescribed. It will be noted in the example of FIG. 4D that standby site104(2) has received, from its primary site 102(2), a redo log messagefor an action (but not a commit action) for transaction Trx2 at time T0.This indicates that the primary site 102(2) is at least in the preparephase in respect of transaction Trx2 at time T0. However, by time T2,standby site 104(2) has not yet received a commit action redo log with aCSN value for transaction Trx2 from its primary site 104(2). As notedabove, first standby site 104(1), which is also involved in transactionTrx2, can commit Trx2:CSN3 as it has received the commit action redo logfor transaction Trx2, including Trx2:CSN3 (and CSN3<=CP=3). In someexamples, the combination of: (i) second standby site 104(2) receiving aprepare-phase action redo log for Trx2 at time T0, (ii) second standbysite 104(2) receiving a commit action redo log at time T1 fortransaction Trx5:CSN5; and (iii) first standby site 104(1) receiving acommit action redo log at time T2 for transaction Trx2:CSN3, can beinterpreted to indicate that second standby site 104(2) can also committransaction Trx2 at Time T2 even though the commit action redo logupdate for transaction Trx2 has not been received by second standby site104(2).

Thus, in at least some examples that include 2PC transactions, thetheorem noted above can be extended to include transactions that havebeen prepared on multiple standby sites, but for which a CSN number hasonly been received at one or some, but not all of the standby sites. Insuch cases, the theorem of atomicity and dependency correctness for theuse a CSN based transaction log stream tracking method can be stated asfollows: For a 2PC transaction TrxA with a CSN value of X, if everystandby site in a group of standby sites has seen a maximum CSN at leastas large as X and at least one standby site in the group has seen theCSN value of X, then the 2PC transaction TrxA can be committed at allstandby sites that have prepared for transaction TRxA.

Accordingly, in an example embodiments, standby sites 104(1) to 104(3)each track a current global CP, which they can each use to determinewhether to commit transactions for which they have received redo logs inrespect of.

FIG. 4E illustrates a further example of CP based processing in thecontext of single site transactions committed at respective primarysites. In this example, distributed database system 100 includes a groupof two primary sites 102(1), 102(2) (not shown in FIG. 4E) and theirrespective first and second standby sites 104(1)-(2). In the illustratedexample, transactions Trx2, Trx3 and Trx4 are committed at primarysites. Transactions Trx2, Trx4 are performed at primary site 102(1) andassigned CSN's 2, and 4 respectively by primary coordinator 122.Transactions Trx3 is performed at primary site 102(2) and assigned CSN's3. At time T0, the first standby site 104(1) receives a redo log message112(1) that includes commit action redo log 106C(1) for transaction Trx2with a CSN value of CSN2. At time T1, the first standby site 104(1)receives a message that includes commit action redo log 106C(1) fortransaction Trx4 having a CSN value of CSN4, and the second standby site104(2) receives a message that includes commit action redo log 106C(2)for transaction Trx3 having a CSN value of CSN3. Thus, at time T1, thecurrent CP value is CP=3. At time T1, first standby site 102(1) has twotransactions that are waiting to be committed, namely transaction Trx2(with CSN2) and transaction Trx4 (with CSN4). Given that the CSN value,CSN2, for transaction Trx2 is less than the current CP=3, but the CSNvalue, CSN4, for Trx4 is greater than current CP=3, at time T1 firststandby site 102(1) will commit transaction Trx2, but will delaycommitting transaction Trx 4. For second standby site 104(2), the CSNvalue of CSN3 for transaction 3 is equal to or less than less thancurrent CP=3, and accordingly standby site 104(2) will committransaction Trx3.

Two solutions for tracking the position of transactions in a transactionstream have been described above. In one solution, an SDV based Lamportclock approach is applied in which a vector at each primary site is usedto store information about the relative position of all sites in thetransaction stream, with the local LSN's of commit actions indicatingrelative transaction offsets within the transaction stream. In a secondsolution, a transaction ID and CSN assigned by a coordinator is used toindicate the offset of a transaction in the transaction stream. In afurther example, a hybrid solution that relies on both SDVs andtransaction ID/CSN pairs may be employed. For example, the distributedcomputer system, 100 may be configured to provide to levels of standbyprocessing based on importance of the transactions being backed up. Insuch examples, transactions may be categorized by primary sites and/orprimary coordinator 122 as “normal” transactions” or “importanttransactions” based on predetermined importance criteria or threshold.The criteria may, for example, be defined based on one or more of theidentity of the parties participating in a transaction, the size of thetransaction, the nature of the items represented in the transaction,and/or other criteria and combinations thereof. In the case of normaltransactions that fall below the importance criteria or threshold,transaction stream tracking may be performed based only on transactionID/CSN values. In the case of important transactions that meet or exceedthe importance criteria, transaction stream tracking may be performedboth at the primary and standby site sides of database system 100 usingboth transaction ID/CSN values and SDV's. For example, upon becomingaware that an important transaction is being prepared at one or moreprimary sites, SDV tracking can be added in respect of the importanttransaction and other transactions that occur within a defined timevicinity of the important transaction. The additional SDV informationcan be sent in the site specific commit action redo logs, along with theCSN value assigned to the committed transaction. In the event that thetransaction CSN values (and resulting CP value) does not support astandby update for an important transaction to be processed, thenreference could be made by a standby site to the SDV information, whichmay enable the transaction to be properly backed up.

FIG. 5 illustrates an example processing system 500, which may be usedto implement methods and systems described herein, such as instances ofprimary sites 102, standby sites 104, coordinator 122, and coordinator422 in a distributed computer system such as database system 100. Otherprocessing systems suitable for implementing the methods and systemsdescribed in the present disclosure may be used, which may includecomponents different from those discussed below. Although FIG. 5 shows asingle instance of each component, there may be multiple instances ofeach component in the processing system 500.

The processing system 500 may include one or more processing units 502,such as a processor, a microprocessor, an application-specificintegrated circuit (ASIC), a field-programmable gate array (FPGA), adedicated logic circuitry, or combinations thereof. The processingsystem 500 may also include one or more input/output (I/O) interfaces514, which may enable interfacing with one or more appropriate inputdevices and/or output devices (not shown). One or more of the inputdevices and/or output devices may be included as a component of theprocessing system 500 or may be external to the processing system 500.The processing system 500 may include one or more network interfaces 508for wired or wireless communication with a network. In exampleembodiments, network interfaces 508 include one or more wirelessinterfaces such as transmitters that enable communications in a network.The network interface(s) 508 may include interfaces for wired links(e.g., Ethernet cable) and/or wireless links (e.g., one or more radiofrequency links) for intra-network and/or inter-network communications.The network interface(s) 508 may provide wireless communication via oneor more transmitters or transmitting antennas, one or more receivers orreceiving antennas, and various signal processing hardware and software.In this regard, some network interface(s) 508 may include respectiveprocessing systems that are similar to processing system 500. In thisexample, a single antenna 516 is shown, which may serve as bothtransmitting and receiving antenna. However, in other examples there maybe separate antennas for transmitting and receiving.

The processing system 500 may also include one or more storage devicessuch as storage units 513, which may include a non-transitory storageunit such as a solid state drive, a hard disk drive, a magnetic diskdrive and/or an optical disk drive. The storage devices of processingsystem 500 may include one or more memories 510, which may include avolatile or non-volatile memory (e.g., a flash memory, a random accessmemory (RAM), and/or a read-only memory (ROM)). The storage devices(e.g., storage units 513 and/or non-transitory memory(ies) 510) maystore instructions for execution by the processing device(s) 502, suchas to carry out the present disclosure. The memory(ies) 510 may includeother software instructions, such as for implementing an operatingsystem and other applications/functions. In some examples, one or moredata sets and/or module(s) may be provided by an external memory (e.g.,an external drive in wired or wireless communication with the processingsystem 500) or may be provided by a transitory or non-transitorycomputer-readable medium. Examples of non-transitory computer readablemedia include a RAM, a ROM, an erasable programmable ROM (EPROM), anelectrically erasable programmable ROM (EEPROM), a flash memory, aCD-ROM, or other portable memory storage.

There may be a bus 514 providing communication among components of theprocessing system 500, including the processing device(s) 502, I/Ointerface(s) 504, network interface(s) 508, storage unit(s) 513, andmemory(ies) 510. The bus 514 may be any suitable bus architectureincluding, for example, a memory bus, a peripheral bus or a video bus.

In some examples, the processing system 500 may be applied in each ofthe primary sites 102 as discussed in the examples of FIGS. 1-4E. Ifthere is change made to the primary site 102, the redo log 106 includingthe vector 108 made of LSNs to indicate transaction offsets of eachassociated primary site may be stored in the storage units 513 or thememories 510. In the case where CSNs are used to record the committedtransaction at primary sites 102, the storage units 513 or the memories510 may store the redo log 106 that includes an assigned relationshipidentifying each committed transaction ID corresponds to a CSN. Theprimary site 102 continuously sends updates regarding the stored redolog 106 to a corresponding standby site via the network interface 508,in order to support data backup that will enable asynchronous datarecovery.

In some examples, the processing system 500 may be applied in each ofthe standby sites 104 as discussed in the examples of FIGS. 1-4E. Thestandby sites 104 receives the transmitted updates to redo log 106 viathe network interface 508, and determine whether replay the receivedredo log 106 or roll back the received redo log 106 using the processingdevice 502.

In some applications, a processing system 500 may be used to implement aprimary coordinator 122 and/or standby coordinator 122′ to coordinateactions between primary sites and standby sites, respectively. In atleast one configurations, prior to making changes (e.g., committingtransactions) at primary sites, the primary coordinator 122 determineswhich primary sites and how many primary sites are involved in atransaction or participate in an transaction by using the processingdevice 502. In that way, the number of LSNs in a SDV 108 is thereforedetermined based on the number of primary sites to participate in thetransaction.

The present disclosure provides certain example algorithms andcalculations for implementing examples of the disclosed methods andsystems. However, the present disclosure is not bound by any particularalgorithm or calculation. Although the present disclosure describesmethods and processes with steps in a certain order, one or more stepsof the methods and processes may be omitted or altered as appropriate.One or more steps may take place in an order other than that in whichthey are described, as appropriate.

Through the descriptions of the preceding embodiments, the presentinvention may be implemented by using hardware only, or by usingsoftware and a necessary universal hardware platform, or by acombination of hardware and software. Based on such understandings, thetechnical solution of the present invention may be embodied in the formof a software product. The software product may be stored in anon-volatile or non-transitory storage medium, which can be a compactdisk read-only memory (CD-ROM), USB flash drive, or a hard disk. Thesoftware product includes a number of instructions that enable acomputer device (personal computer, server, or network device) toexecute the methods provided in the embodiments of the presentinvention.

Although the present invention and its advantages have been described indetail, it should be understood that various changes, substitutions andalterations can be made herein without departing from the invention asdefined by the appended claims.

Moreover, the scope of the present application is not intended to belimited to the particular embodiments of the process, machine,manufacture, composition of matter, means, methods and steps describedin the specification. As one of ordinary skill in the art will readilyappreciate from the disclosure of the present invention, processes,machines, manufacture, compositions of matter, means, methods, or steps,presently existing or later to be developed, that perform substantiallythe same function or achieve substantially the same result as thecorresponding embodiments described herein may be utilized according tothe present invention. Accordingly, the appended claims are intended toinclude within their scope such processes, machines, manufacture,compositions of matter, means, methods, or steps.

1. A method comprising: generating, by a first primary site that isincluded in a group of primary sites of a distributed database system, acommit action redo log message for a commit action performed by thefirst primary site for a first database transaction, the commit actionredo log message including a transaction ID for the first databasetransaction and a transaction order indicator that represents an orderof database transactions in a group of database transactions performedat one or more primary sites of the group of primary sites; and sending,by the first primary site, the commit action redo log message, for acorresponding first standby site that backs up the first primary site.2. A first primary site included in a group of primary sites thatparticipate in database transactions, comprising: a processing systemcomprising one or more processing units and one or more storage devicesstoring instructions that are operable, when executed by the one or moreprocessing units, to cause the first primary site to perform operationscomprising: generating a commit action redo log message for a commitaction performed by the first primary site for a first databasetransaction, the commit action redo log message including a transactionID for the first database transaction and a transaction order indicatorthat represents an order of database transactions in a group of databasetransactions performed at one or more primary sites of the group ofprimary sites; and sending the commit action redo log message for acorresponding first standby site that backs up the first primary site.